feat(notebook-migration-service): compute jupyter iframe url per request - #7602

apache#7738)

### What changes were proposed in this PR?
Uploads each workflow's notebook to Jupyter under a per-workflow
filename instead of a single shared `notebook.ipynb`.

Before this change the frontend always uploaded to
`work/notebook.ipynb`. That was safe across users (each runs their own
pod) but not across one user's workflows: every workflow wrote to the
same file, so opening a second workflow overwrote the first, and because
nothing writes back from Jupyter, any edits made in the panel were lost.
Two tabs on different workflows also collided on the same file. This PR
keys the notebook file on the workflow id (`notebook_<wid>.ipynb`) so
each workflow has its own.

The backend already accepts this (from apache#7602): `get-jupyter-iframe-url`
takes an optional `notebookName` query param and `set-notebook` accepts
any `[A-Za-z0-9._-]+\.ipynb` name, which `notebook_<wid>.ipynb`
satisfies. No backend change is needed.

**`NotebookMigrationService`**
- Adds an exported `notebookFileName(wid)` helper (mirrors the existing
`notebookMappingKey`) that returns `notebook_<wid>.ipynb`, or the
default when there is no wid.
- `sendNotebookToJupyter(notebookData, notebookName)` takes the name
instead of hardcoding it.
- `getJupyterIframeURL(notebookName?)` sends the name as the
`notebookName` query param when given, and omits it otherwise so the
backend default still applies.

**`JupyterPanelService` (owns the name)**
- Adds a private `currentNotebookFileName()` that derives the filename
from the current workflow's wid, and uses it for both the upload and the
iframe fetch so the two can never derive different names.
- Adds a public `getJupyterIframeURLForWorkflow()` that the panel calls
to get the URL for the current workflow's notebook.

**`JupyterNotebookPanelComponent` (view)**
- Calls `jupyterPanelService.getJupyterIframeURLForWorkflow()` and drops
its now-unused direct dependency on `NotebookMigrationService`.

Because the upload and the iframe fetch both go through
`currentNotebookFileName()`, the file that is written and the file the
panel requests are always the same, and switching workflows produces a
distinct `notebook_<wid>.ipynb` rather than overwriting a shared one.

### Any related issues, documentation, discussions?
Closes apache#7671
Parent issue apache#4301

Follow-up: deleting a notebook now leaves its `notebook_<wid>.ipynb`
file in the Jupyter pod, since `deleteNotebookAndMapping` only removes
the database rows. This was self-limiting under the old single-file
scheme. Tracked in apache#7737

### How was this PR tested?
- `notebook-migration.service.spec.ts`: `notebookFileName` mapping, the
request body carrying the name on `sendNotebookToJupyter`, and the
`notebookName` query param being present when a name is given and absent
when it is not.
- `jupyter-panel.service.spec.ts`: the upload uses the wid-derived
filename, `getJupyterIframeURLForWorkflow` forwards that same filename
to the HTTP client, and the disabled-flag path returns null without any
HTTP call.
- `jupyter-notebook-panel.component.spec.ts`: the panel fetches its URL
through `getJupyterIframeURLForWorkflow`.

### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Opus 4.8)